1. Field of the Invention
The present invention relates to a method for connecting a one-to-one or one-to-many push-to-talk-over-cellular (PoC) session for an Open Mobile Alliance (OMA) PoC call service using a PoC Box as a storage system substituted for a general PoC client, and transmitting and managing PoC media after participating in the session.
2. Description of the Related Art
Current PoC technology generally utilizes Session Initiation Protocol (SIP) or Extended SIP, an application-layer protocol, for controlling Internet multimedia communication (IP telephony) in order to transmit session participation information of PoC group talks, and an Extensible Markup Language (XML) Configuration Access protocol (XCAP) in order to obtain information on a group. The basic definition, structure, and function of a conventional PoC system will be described below on the basis of these protocols.
Significant developments in mobile communications technology and the extension of mobile communications networks have resulted in the development of a vast array of services and applications for use with a cellular phone. Concurrently, there is an increasing demand from cellular phone users for additional services, such as a location, multimedia, and push-to-talk (PTT) services. Among these additional services, the PTT service supports various supplementary functions such as instant messenger and a status display, as well as a group call and a voice call, which are also provided by an existing radio or a trunk radio system (TRS).
Standardization of a PoC service that utilizes the push-to-talk (PTT) function in a mobile communication network is currently taking place. One unique feature of the PoC service that differs from an existing mobile communication service is that a user can participate in a plurality of PoC sessions, and thus, can use a call service while moving among the PoC sessions as desired. This feature is a requirement that is specified in the OMA, which is a forum for specifying mobile communications services.
The PoC service can accompany a service for establishing a group session as in a conference call. Accordingly, the OMA specification defines an XML Document Management (XDM) Client (XDMC) and XDM Server (XDMS) for providing a group list service
FIG. 1 is a schematic diagram illustrating XDM architecture. Referring to FIG. 1, user equipment (UE) 10 that requests a PoC service is connected to a Session Initiation Protocol/Internet Protocol (SIP/IP) core 30 that supports SIP and IP multimedia via an access network 20. The UE 10 is an XDMC capable of residing in a PoC terminal, and includes an XDMC 12 and a PoC client 11 requesting the PoC service.
The PoC client 11 resides in a PoC user terminal to provide access to the PoC service. The PoC client 11 mainly serves to establish, participate in, and terminate the established PoC session. In addition, the PoC client 11 creates and transfers a media burst, supports an instant personal alert, and authenticates when providing access to the PoC service. Hereinafter, unless otherwise stated, the PoC client 11 is assumed to be the same as a PoC service subscriber.
The SIP/IP core 30 is connected to a shared XDMS 40, a PoC XDMS 50, a PoC server 60, and a presence server 70 in order to support the PoC service. The PoC server 60 has a Controlling PoC Function for maintaining and managing the PoC session, or a Participating PoC Function for participating in the PoC session for a one-to-one PoC call or a one-to-two or more PoC call.
The XDMS can be classified into the PoC XDMS 50, which is specific to the PoC service, and the shared XDMS 40, which is commonly used in a different service enabler. Further, the XDMS includes the Aggregation Proxy 90 that routes a group list relevant request to each XDM server according to a certain rule when receiving the group list relevant request from the XDMC 12. The protocols and details for the XDM, such as creating, modifying and deleting the group list, are well-known among those skilled in the art, and so their detailed description will be omitted herein.
In general, SIP or Extended SIP, i.e., an application-layer protocol for controlling Internet multimedia communication (IP telephony), are mainly used to transmit session participation information of PoC group talks. SIP is a standard defined in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 2543. SIP is an application-layer control protocol that is used to set up, modify, and terminate a session or call for multimedia communication such as video and voice communication. SIP exists over a User Datagram Protocol (UDP)/TCP/IP layer, which supports both unicast and multicast sessions for initiating a session by inviting participants to a multimedia conference with a client/server protocol capable of exchanging SIP Request and Response messages in a request/response fashion.
The SIP Request message provides six functions in RFC 2543: INVITE (Invitation to participate in a session); ACK (Acceptance of an INVITE request); BYE (Termination of a call); REGISTER (Registration with the database of a redirect server by a user agent); CANCEL (Cancellation of a request in a queue); and OPTIONS. The SIP Response message provides status codes including: 1xx (Information response); 2xx (Successful response); 3xx (Redirection response); 4xx (Client Error, Request Failure); 5xx (Server Error); and 6xx (Global Failure).
FIG. 2 illustrates a schematic configuration of a conventional PoC server. The PoC server performs both a Controlling PoC Function (hereinafter CF) to control overall maintenance and management of a PoC session, and a Participating PoC Function (hereinafter PF) for controlling maintenance and management between each PoC session, which will be explained below with reference to Tables 1 and 2.
TABLE 1Controlling PoC Function (CF)Provides centralized PoC session handlingProvides centralized Media distributionProvides centralized Talk Burst Arbitration functionality including talkeridentificationProvides SIP session handling, such as SIP session origination,termination, etc.Provides policy enforcement for participation in group sessionsProvides participant informationCollects and provides centralized media quality informationProvides centralized charging reportsMay provide transcoding between different codecsSupports Talk Burst Control Protocol Negotiation
As shown in Table 1, the PoC server performing the CF (or the Controlling PoC server) manages a PoC session. In particular, the Controlling PoC server receives requests for the floor from PoC clients, arranges an order in which to give the clients the floor, and gives the clients the floor in that order. The Controlling PoC server also distributes a talk burst, for which an arbitrary PoC client makes a request, to all other PoC clients participating in a group PoC call, and provides information of the PoC clients participating in the group PoC call.
As shown in Table 2 below, the PoC server performing the PF (or the Participating PoC server) manages a PoC session between the Controlling PoC server and each PoC client. In particular, the Participating PoC server relays the floor between the PoC client and the Controlling PoC server when the PoC client makes a request for the floor or when the Controlling PoC server gives the floor to the PoC client. In addition, the Participating PoC server relays media between the Controlling PoC server and the PoC client, performs transcoding between different codecs, and filters one of two concurrent PoC sessions according to the choice of a PoC user when there is simultaneous talking in the two active PoC sessions.
TABLE 2Participating PoC Function (PF)Provides PoC session handlingMay provide the Media relay function between PoC client and ControllingPoC serverMay provide user media adaptation proceduresMay provide the Talk Burst control message relay function between PoCclient and Controlling PoC serverProvides SIP session handling, such as SIP session origination,termination, etc, on behalf of the represented PoC clientProvides policy enforcement for incoming PoC session (e.g. accesscontrol, incoming PoC session barring, availability status, etc.)May collect and provide media quality informationProvides participant charging reportsMay provide filtering of media streams in the case of simultaneoussessionsMay provide transcoding between different codecsMay support Talk Burst Control Protocol NegotiationStores the current Answer Mode and Incoming PoC Session Barringpreferences of the PoC client
In the PoC service system described above, the PoC user can input information on groups and their members into a Group and List Management Server (GLMS) through the PoC user's terminal, and can receive information about other PoC users with whom the PoC user can talk through an individual or group list transmitted from the GLMS. Alternatively, in order to create, modify, and manage groups and their members, the information on the groups and their members may be input into the GLMS via a communication network, such as the Internet or an Intranet.
In order to use the PoC call service, the PoC user registers its PoC address with the SIP/IP core 30. The SIP/IP core 30 stores information on the PoC user by request of the PoC user. Accordingly, when another PoC user tries to request the group PoC call, the PoC user registers its information with the SIP/IP core 30 in advance as described above, and requests the group PoC call to its SIP/IP core 30 by using group identification information transmitted from the GLMS.
The SIP/IP core 30 performs addressing and domain locating by using information of the requesting PoC user, and then transfers a PoC call request to a home PoC server 60 with which the requesting PoC user is registered. In regard to the PoC call request, the PoC server 60 prepares to establish a PoC session, obtains each user's information from the GLMS, and then transfers a PoC call request signal to the SIP/IP core 30. When the PoC call request is made to users within an Intradomain, the PoC server 60 performs both the CF and the PF. The PoC server 60 managing the call-requested PoC user requests the PoC call to the PoC user after locating the SIP/IP core 30 by use of the PoC user's information transmitted to the PoC server 60.
FIG. 3 is a schematic diagram illustrating CF and PF blocks of a PoC server. Referring to FIG. 3, PoC clients 111, 121, 131, and 141 provide access to a CF 100 through PFs 110, 120, 130, and 140 respectively, thereby establishing a PoC session. When the floor is granted to a requester qualified as a talker from the CF 100, speech media of the corresponding PoC client is transmitted to each PoC client. The PoC user who is granted the floor cannot appropriately speak until the user confirms information of the participants participating in the PoC group session.
The PoC system required by the OMA has the following features.
First, the terminating side can set up its own answering modes according to the request of a PoC user. The answering modes can be either auto or manual.
If the terminating side is registered in a user list for the auto answer mode, the terminating side can immediately send an answer to the originating side in a corresponding network in place of the manual answer of a recipient. The automatic answer is sent instead of operating the terminal in the network because the PoC server stores the answering mode and the corresponding user list according to a request of the terminal to set the answering mode.
The manual answer mode corresponds to when the user is not included in an automatic answer user list or where the answer is ambiguous, or the recipient sets all users to make the manual answer. In the manual mode, a PoC call request is transmitted to the user's terminal through a terminating network and then a call is connected by acceptance of the PoC user.
Second, the PoC system is divided into two modes, an on-demand session mode and a pre-established (or early) session mode, according to the type of connection with a PoC server within a user's home network. The pre-established session mode is designed so that the PoC user sets a session between a PoC client and a PoC server belonging to a PoC user's home network in advance by the PoC user's request. The pre-established session enables the PoC user to negotiate media parameters to be used with the PoC server in advance, and thus advance rapid session establishment without renegotiating the media parameters to be used in the future between the PoC server and client.
In order to set the pre-established session, the PoC client provides supported media parameters to a Session Description Protocol Multipurpose Internet Mail Extensions (SDP MIME) body through a SIP INVITE method, and responds to the media parameters provided from the PoC server. The PoC client sends, to the PoC user, identification information of the pre-established session for a response message received from the PoC server, together with a conference Uniform Resource Identifier (URI). When using the pre-established session, it is possible to pre-negotiate such parameters as an IP address, a port number, a codec to be used and a Talk Burst Control Protocol (TBCP) for controlling a talk burst.
The on-demand session mode refers to a state in which the PoC user does not set the pre-established session, and indicates that the PoC user performs a PoC call connecting procedure after receiving an invitation message of another PoC user.
Hereinafter, a process of establishing a PoC session of the PoC system will be described with distinction between the originating side and the terminating side.
First, an originating PoC client A sends an SIP INVITE request message, which includes the SIP address of a recipient to whom the PoC client A desires to talk, to a corresponding SIP/IP core A. The INVITE request message includes information such as a PoC address of the call-requesting client, requested media parameters (because the requested session is based on the multimedia, having various media attribute values such as an audio and video encoding method, a rate and a payload type), and an attribute value informing PoC service and so on, and is forwarded to a PF via corresponding IP Multimedia Subsystem (IMS) servers (Proxy Call Session Control Function (P-CSCF) and Serving Call Session Control Function (S-CSCF)) in an IMS network through a route query at a Dynamic Host Configuration Protocol (DHCP) server or Domain Name System (DNS) server. Because the PF, to which a PoC user is connected at a general call request, can be implemented as an entity different from a CF that manages the talk burst of an established session, the INVITE request message forwarded previously is transmitted to the CF via an SIP/IP core of the corresponding network.
A PoC session controlling network including the CF transmits the INVITE request message to the terminating network, and then receives a response message. The SIP response message with which the terminating network responds may be one of a provisional response message of 1XX, a successful response message of 2XX, and an error response message of 4XX, 5XX or 6XX. If an AUTO-ANSWER mode is set, the CF can receive a SIP 183 Session Progress signal and thus perform connection between the PoC server and the PoC client in the IMS network of the call requester. The call acceptance signal of the recipient responds with the SIP 183 Session Process or SIP 200 OK response and is forwarded to the PoC client A via the CF and PF, the PoC servers.
After receiving the 200 OK or 183 Session Progress response from the terminating PoC server, the CF determines that a PoC call is connected and then sends a Floor Granted signal, which gives the talk burst floor to the PoC client A. Granting of the talk burst authority according to the response (200 OK or 183 Session Progress) can be divided into confirmed and unconfirmed. When receiving the unconfirmed response, the CF requires a buffering function.
After receiving the response signal to the INVITE request signal, the originating PoC client A receives the Floor Granted signal forwarding a talk burst transmission enable signal (i.e. a ring back tone) using a Real-time Transport Protocol (RTP) Control Protocol (RTCP). At this time, the Floor Granted signal is generated from the CF having the authority to arbitrate the talk burst, and transmitted to the corresponding PoC client via the PF, which manages the corresponding PoC client. The Floor Granted signal can be transmitted without passing through the SIP/IP core because it uses a bearer's route rather than the SIP. Finally, the PoC user that confirms the ring back tone transmits a media stream (e.g., voice) using an RTP.
The OMA PoC Release 2 takes into account a PoC Box, which has a function somewhat similar to a conventional multimedia message (MM) Box in order to further extend the PoC service. According to a PoC Box service, on behalf of a client of the PoC user who cannot participate in the one-to-one or group PoC session in real time, a specific physical or logical system (e.g., a PoC Box) participates in a corresponding PoC session, stores media transmitted during the session, and then transmits/reproduces the stored media at the request of the PoC user.
Accordingly, in order to implement the PoC Box service, which is not provided in conventional PoC standard technology, a PoC client is required to prepare for performing methods for requesting the PoC Box service, setting a type of media to be provided with the PoC Box service, and determining whether the PoC Box service is used or not.